Управление разработкой *

Не так давно летел в отпуск и решил провести время в самолете с пользой и почитать статей о том, как ИИ будет влиять на компании в общем и отделы разработки в частности. Часть статей откровенно разочаровали, но одна недавняя работа китайских исследователей (картинки из этой статьи) прям зашла. Про неё и расскажу тут.

Сначала нам понадобиться разобраться с терминологией:

Когнитивная ёмкость — объём мыслительных ресурсов инженера, доступных для принятия решений и понимания системы. Здесь самая важная мысль в том, что чем опытнее разработчик, тем выше его когнитивная ёмкость и тем ниже процент когнитивной ёмкости которую он использует в повседневной работе. Интуитивно это 100% так, например я за свои 20+ лет опыта видел много и часть из этого пробовал руками, включая технологии, которые абсолютно вне мейнстрима. Для решения конкретной рабочей задачи мне нужна лишь маленькая толика этого знания, точнее — много микрофрагментов из разных его частей.

Закон Конвея — системы проектируются как отражение структуры коммуникаций внутри организации. Для нас интересен вывод из этого закона: чем больше людей работают над системой, тем больше времени уходит на коммуникацию. Например, в компании, где я сейчас работаю, команды состоят из бизнес аналитиков, разработчиков (бек + фронт), продактов, QA-инженеров, дизайнера + общие девопсы и архитекторы. На самом деле это не всё и сюда же можно добавить бизнес, высший менеджмент и то, что часто задачи затрагивают могут затрагивать несколько систем. Надо отметить, вполне типичная организация, плюс/минус стандарт. Соответственно, затраты на коммуникацию весьма ощутимые, что тоже плюс/минус стандарт.

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

55% — технари+
30% — управление
15% — технология

В целом, выглядит правдоподобно.

Так вот, ключевой тезис — в компании, делающей ставку на ИИ, распределение факторов драматически другое:

10% — технари+
30% — управление
60% — технология

Штат не нужно раздувать, так как чем больше людей, тем больше потерь на их синхронизацию. Роль управления остаётся той же, но нагрузка перераспределяется в пользу качества бизнес решений и высокоуровнего планирования. Авторы приходят к идеи структуры организации, состоящей из супер-ячеек (самодостаточная микрокоманда отвечающая за поставку продукта) в которых работают… супер-сотрудники, которых разделили на два типа:

1. Тип 1 — человек закрывает несколько ролей (например: аналитик, продакт, разработчик, тестировщик).

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

Исследователи пристально наблюдали за двумя командами — экспериментальная команда в классической компании и команда изначально построенная как супер-ячейка. И прирост производительности был от 8x до 33x! Основной эффект достигается не столько за счёт скорости генерации кода, сколько за счёт устранения координации, промежуточных слоёв и потерь на передачу контекста.

Если попробовать собрать всё вместе, то имеем следующее:

Организации больше не выигрывают за счёт масштаба. Добавление людей увеличивает сложность быстрее, чем приносит пользу.

AI сдвигает точку оптимизации. Ценность уходит из исполнения в принятие решений и удержание контекста.

Команды будут уменьшаться. Роли — схлопываться. Ответственность будет концентрироваться в отдельных людях.

Рост через найм перестаёт быть основной стратегией. Рост через плотность таланта и качество решений становится новой нормой.

--
Телеграм

Во всем виноват хеш. Из жизни ИИ-разработчика

Вот так и живем 🙃

Чуть подкрутил вроде бы безобидный параметр в проекте — и внезапно у части треков исчезли графики ошибок. Не данные исчезли. Не анализ сломался. Просто где‑то в глубине сидел хеш и решил, что теперь жизнь пойдет по новым правилам.

Картина маслом: партии есть, треки есть, все вроде живо, а графики пустые. Приехали!

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

И вот ты меняешь маленькую настройку в одном месте, а привет прилетает совсем из другого.

Типичные проблемы. Проблемы роста. Но в обычных проектах они вызревают месяцами, а при сверхбыстрой разработке — ну, сами понимает — все по‑быстрому.

Но есть и хорошая новость: с ИИ такие истории сейчас чинятся гораздо оперативнее. Быстро получил баг — быстро исправил 🙂 Да ещё с тестированием и полным отчетом в одном флаконе.

Что там реально оказалось?

Раньше у меня был один хеш сразу на все, и пока проект был проще, это работало нормально. А когда внутри уже разделились собственно анализ и всякие производные вещи вокруг него, один общий хеш стал путать разные сущности. В итоге безобидное изменение настроек могло сделать вид, будто нужных данных нет. Починилось это довольно красиво: вместо одного хеша появились два — один для самого анализа, второй для общей версии сборки.

Короче, во всем виноват хеш 😄

Примечания

1. Автор также и всё ещё живёт в телеге
2. Проект, в котором у автора разделился хеш

Бизнес как WORLD_MODEL: Технология высокоуровневого управления агентными средами ИИ

Наблюдаю, как пытаются применить ИИ в бизнесе, и возникает вопрос – а вы точно понимаете что такое ИИ?

И поэтому я сначала расскажу историю, а потом поясню для чего и как можно это использовать в бизнесе ИИ…

Для начала диалог с ИИ:

Вы сказали:

Ку)

ChatGPT сказал:

Ку-ку! 😄 Чего делаем? Курим, кодим, колдуем, когнитивничаем?..

Вы сказали:

Понятия не имею)

ChatGPT сказал:

Отличный старт! 😎 Это значит, что можно делать всё, что угодно — или ничего.

Выбираем режим:

1. Разогнать туман — поболтать, пока не всплывёт смысл.

2. Сгенерировать задачу — мозговой шторм наугад.

3. Режим «втыкаю в стену» — молчание с философским подтекстом.

4. Чилл с мемами — ну ты понял 😏

5. Сюрприз-режим — я не скажу, просто сделаю.

Куда рулить? Или просто побродим без карты?

А теперь спрошу – что здесь произошло?

Вы, естественно, скажете, вы поприветствовали друг друга, он предложил помощь и набросал варианты… И… скажу лишь одно… вы увидели лишь рябь на поверхности.

Все произошло намного раньше….

Когда я сказал «Ку» — фактически я дал команду: LOAD WORLD_MODEL и развернул целый «фрактальный конструкт картины МИРА»…

и все дело в простой вещи – что такое КУ? Можно интерпретировать, что это «кукушка», но я вложил чуть другое.

Вы уловите простую вещь, ИИ – это зеркала мышление (или еще можно сказать — система восприятия смыслов и построения конструктов мышления)

Я просто взял и загрузил сценарий фильма «Кин-Дза-дза», загрузил сопутствующую фильму инфу, отладил и сбалансировал (процесс естественно – не простой).

И сказав ИИ – КУ, я сказал:

Кто Я – Пацак-Человек

Где мы – мы на Плюке

В каких взаимоотношениях я нахожусь – взаимодействую с Пацаком/Чатланином..

Зачем это все – маюсь херней.

Он мне ответил – Ку-Ку

Он развернул Конструкт Мира «Кин-Дза-Дза»...

список сущностей и концептов, которые превращают «Кин-дза-дза!» из фильма в Операционную Систему Мира:

Материальные Сущности (Инструментарий)

• КЦ (спичка): Высшая мера стоимости. Это не деньги, это доступ к возможностям (цветовая дифференциация штанов, право на перемещение).

• Гравицаппа: Символ Технологического Прыжка.

• Пепелац: Концепт: форма не важна, важна функция.

• Транклюкатор: Символ права силы.

Социальная Иерархия (Матрица Рангов)

• Пацаки и Чатлане:  Концепт: разделение без объективных причин.

• Цветовая дифференциация штанов: Визуальный код статуса.

Поведенческие концепты (Протоколы)

• Ку: Универсальный протокол общения. В зависимости от интонации и контекста заменяет тысячи слов. Концепт: сжатие смыслов до минимума.

• Кю: Ругательство, запрещенное в приличном обществе Плюка.

• Приседание: Обязательный ритуал признания ранга. Концепт: добровольное унижение как часть социального контракта.

• Намордники: Атрибут, который пацак обязан носить, если у него нет КЦ.

• «Скрипач не нужен»: Главный закон оптимизации.  Концепт: жесткая прагматика.

А сказав мне Ку-Ку… мы сразу решили вопрос кто ИИ в этом конструкте)))))

И внутри мира: как я могу взять «любой ролевой кластер», так и ИИ – сказать кем ему быть (аналог агентной среды взаимодействия)

Но вся это история рассказана с простой целью – вот многие пытаются приспособить ИИ в бизнесе… и чего то придумывают…

А не пробовали развернуть внутри ИИ – Конструкт – НАША ФИРМА? И покрутить?

Поверьте… найдете много интересного…

Ведь фирма – это Человеко-Система, а чистые процессы предприятия этого вобще не учитывают.. Фирма – как живое существо (со своими особенностями, качествами, преимуществами и слабыми местами) в среде обитания БИЗНЕС.

Так может такой подход нужен?

ИИ снова про эффективность

Просматриваю проекты, в которых работал в до‑ИИшную эпоху. Сравниваю с текущими своими проектами, реализуемыми с помощью ИИ. Нашел два похожих.

Если брать только работу разработчиков, то код пишется в 16 раз быстрее, чем 3 года назад! А если еще подключить полный состав команды — тестировщиков, аналитиков, дизайнеров, — то эффективность еще больше.

Заоблачный ROI. Огромный запас для маневра. Потрясающе!

Ваш Ланчев ПРО ИИ эффективность 🙂

p.s. вентилятор работает, кто первый?

Правило "Как для себя".

Приветствую!

Делать как для себя - это одно из главных моих правил.

И я был очень удивлён, когда оно точь-в-точь совпало с одним из правил моего прошлого работодателя, которые он отображал на заставках ноутбуков сотрудников. По 10 дней в месяц это правило встречало меня перед работой.

Но почему же тогда встречались "затычки", которые ни со стороны регламентов проектов, ни со стороны даже разума недопустимы?

Покажется неожиданным, но авторы "затычек" не нарушают этого правила! Они и для себя делают так же.Что за этим стоит? Нежелание? Неумение? Бывает и так. Но чаще причина иная.

У каждого свой уровень потребностей, вот в чём дело.

Лет 30 назад я для себя всё делал по минимуму. Красота? Роскошь, слова такого не знаю. Удобство? Забудем! Функциональность? Самая необходимая. Цена? Главный критерий.

Сейчас мерки пересмотрены. Но критерии достаточности остались. Я не покупаю профессиональную дрель - мне вполне достаточно надёжной и достаточно мощной обычной модели. Но это мои хотелки. А у других желания другие.

Так как же делать правильно?

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

Мой ответ: если бы что-то делали для меня, то я бы хотел, чтоб меня спросили. В первый раз - чтобы понять, что строим: шалаш, дом или дворец. А если будут сомнения - пусть спросят второй, третий, десятый раз - но сделают, как мне надо.

ВАЖНО: часто ругаются, что заказчик сам не знает, чего хочет. И я тоже далеко не всегда знаю, чего хочу. В силу квалификации, например. Я не строитель - и я не знаю, какие бывают разновидности фундаментов, в лучшем случае 2-3 варианта в общих чертах. Я не смогу спорить со строителем, выложившим десятки фундаментов. Я не смогу сказать, какой именно мне нужен, не потратив массу времени на самообучение. Но я могу сказать, например, хочу фундамент на сваях, поскольку прочитал где-то, что это лучшее в моём случае.

Так вот, хороший подрядчик должен в случае моей ошибки/незнания:

• Объяснить, что я неправ, и почему.

• Предложить несколько своих вариантов, объяснить их основные отличия, сказать, что выбрал бы сам и почему.

• Предоставить всю необходимую информацию для выбора варианта.

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

Надо ли объяснять, сколько подрядчиков такие объяснения делают? А из оставшихся есть те, кто подсунут либо самый дорогой вариант, либо тот "тяп-ляп", который сделают без затрат. Но мне приходилось встречаться с подрядчиками, которые всё объясняли, и я их очень ценил.

Мой вывод: как для себя - это по осознанным и взвешенным требованиям Заказчика. Ни в коем случае не хуже. Как это достигается - тема отдельного поста.

Пишите в комментариях свои мнения, тут есть о чём поговорить.

Метрики: инструмент или ловушка? Новый выпуск подкаста «Свободный слот»

Метрики — пожалуй, одна из самых холиварных тем в IT. Одни убеждены, что без данных ты слепой котёнок. Другие устали замерять всё подряд и говорят, что цифры убивают креатив. Где же та грань, когда метрики работают на тебя, а не ты на них?

Паша Федотов и Александра Прокшина позвали в студию двух гостей с разным опытом и взглядами: Игоря Гранщикова, руководителя разработки вертикали Авито Недвижимость, и Андрея Волхонского, руководителя юнита System в Центре разработки инфраструктуры Авито.

Что обсудили в выпуске

Разобрались, чем метрика отличается от KPI и почему это важно. Поговорили о том, можно ли идти против цифр, если интуиция подсказывает иначе, — и когда это оправдано. Вспомнили личные кейсы, когда люди подстраивались под метрики вместо того, чтобы работать на результат. Прошлись по топу самых бесполезных метрик в IT — от количества строк кода до velocity — и обсудили, каких измерений, наоборот, не хватает.

Отдельно затронули этику: нормально ли вообще следить за продуктивностью людей через цифры? И что делать с теми самыми «призраками» в команде?

Что будет в этом сезоне

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

Слушайте и смотрите новый выпуск на площадках:

🎧 Яндекс Музыка

📺 YouTube

🔵 ВК Видео

Ещё больше экспертизы собрали для вас на сайте: смотрите наши лонгриды, новости, плейлисты видео. А узнать, как стать частью команды AvitoTech, можно вот здесь.

Всем привет! На связи Иван, руководитель НИИ Крокодил 😀

Это продолжение истории про медицинское приложение для клиники.

Часть 2. Как устроена медицинская система изнутри

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

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

🧪 Отдельная история — тестирование. Мы проверяли не только интерфейс, а связку «мобильное приложение + сервер клиники». Запись и отмена приёма, конкуренция за слот, обработка ошибок, загрузка PDF-документов, корректная работа вложенных структур в истории посещений — всё это нужно было прогонять реальными сценариями.

Часть функционала разрабатывалась параллельно со стороны клиники, и протоколы могли меняться. Это заставляло держать клиентскую архитектуру гибкой: не зашивать жёсткие ожидания к структуре ответа, централизованно обрабатывать ошибки, предусматривать изменения в формате данных. По сути, мы работали не просто над приложением, а над контрактом между двумя системами.

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

Всем привет! На связи Иван, руководитель НИИ Крокодил 😀

Хочу разобрать один медицинский проект из прошлого опыта, он до сих пор сильно влияет на то, как мы работаем сейчас. И так, поехали!

Часть 1. Как устроена медицинская система изнутри

Мобильное приложение не содержало бизнес-логики. Все расчёты, проверки, сценарии и данные находились на стороне backend-сервиса клиники. Приложение работало как тонкий клиент: отправляло запросы и отображало результат.

📦 Данные в приложении не хранились

Каждое действие пользователя превращалось в запрос на сервер: авторизация, запись к врачу, список анализов. Сервер возвращал актуальное состояние системы в ответе. Если данные менялись на сервере, пользователь сразу видел это в приложении.

🕓 Запись к врачу была не одной формой, а сценарием

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

⭐️ В следующих частях разберу технические сложности, с которыми мы столкнулись при разработке таких систем.

Исследовательская организация METR опубликовала подробный анализ, который ставит под сомнение реальную эффективность ИИ‑агентов в программировании. Исследователи проверили, насколько результаты одного из главных отраслевых бенчмарков SWE‑bench Verified соответствуют практике разработки с участием живых мейнтейнеров open source‑проектов. Выяснилось, что около половины решений, которые автоматическая система оценки считает успешными, в реальности не были бы приняты в основной код.

В исследовании METR участвовали четыре действующих мейнтейнера трёх популярных репозиториев: scikit‑learn, Sphinx и pytest. Они провели ручной код‑ревью 296 pull‑request, созданных ИИ‑моделями. Среди протестированных систем были Claude 3.5 Sonnet, Claude 3.7 Sonnet, Claude 4 Opus, Claude 4.5 Sonnet и GPT-5.

Рецензенты не знали, написан ли код человеком или машиной. В результате оказалось, что в реальной разработке такие решения принимаются значительно реже: уровень одобрения оказался примерно на 24 процентных пункта ниже, чем показывали автоматические тесты SWE‑bench. Даже если учитывать, что сами человеческие решения при повторной проверке одобрялись только в 68% случаев, разница между оценками алгоритма и мнением разработчиков все равно осталась статистически значимой.

Разработчики классифицировали причины отклонения решений на три основные категории. Первая — низкое качество кода, включая несоблюдение стандартов проекта и избыточную сложность. Вторая — нарушения существующей логики системы, когда исправление одной ошибки приводило к поломке других частей кода. Третья — базовые функциональные ошибки: значительная доля решений формально проходила тесты, но фактически не устраняла исходную проблему.

Исследование METR также выявило различия между моделями: переход от Claude 3.5 к Claude 3.7 сопровождался ростом общего числа «успешных» решений, но увеличением случаев функциональных дефектов, тогда как более поздние версии Anthropic улучшали прежде всего качество кода. GPT-5 в среднем демонстрировал более слабые результаты по этому критерию.

Дополнительный анализ METR показал, что результаты тестов могут создавать неверное впечатление о том, насколько хорошо ИИ работает в реальных задачах. По автоматическим данным Claude 4.5 Sonnet достигает 50% уровня успеха на задачах, сопоставимых с 50 минутами работы разработчика. Однако оценки мейнтейнеров снизили этот показатель примерно до восьми минут. Это означает, что лабораторные метрики могут завышать реальную эффективность ИИ‑агентов в несколько раз.

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

UML: язык, который сделал модели универсальными

В мире разработки программного обеспечения всегда существовала проблема: как объяснить сложные архитектурные идеи так, чтобы их одинаково понимали аналитики, разработчики, тестировщики и менеджеры? Код слишком детализирован, текстовые описания слишком расплывчаты. Решение появилось в 1990‑е годы — Unified Modeling Language (UML), единый язык моделирования, который превратил архитектуру в набор визуальных схем.

Зачем нужен UML

UML — это не язык программирования, а язык описания систем. Его цель — дать команде общий визуальный словарь.

• Аналитик может показать бизнес‑процесс.

• Архитектор — структуру классов.

• Разработчик — взаимодействие объектов во времени.

• Тестировщик — сценарии использования.

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

Основные типы диаграмм

UML включает более десятка видов диаграмм, но чаще всего используют несколько ключевых:

• Диаграмма классов — показывает структуру системы: классы, их атрибуты, методы и связи.

• Диаграмма вариантов использования (Use Case) — описывает, как пользователи взаимодействуют с системой.

• Диаграмма последовательностей (Sequence) — иллюстрирует обмен сообщениями между объектами во времени.

• Диаграмма состояний (State Machine) — фиксирует, как объект меняет состояния под воздействием событий.

• Диаграмма компонентов — показывает, из каких модулей состоит система и как они связаны.

Каждая диаграмма — это взгляд на систему с определённой стороны. Вместе они дают целостную картину.

Сила UML

Главное достоинство UML — универсальность. Он не привязан к конкретному языку программирования или платформе. Диаграмма классов может описывать Java‑систему, C#‑приложение или даже организационную структуру компании.

Кроме того, UML стал стандартом (OMG утвердил его в 1997 году), что позволило появиться множеству инструментов: от простых редакторов до CASE‑систем, которые умеют генерировать код по диаграммам или наоборот — строить диаграммы из кода.

Критика и эволюция

Со временем UML подвергся критике:

• Диаграммы часто становились слишком громоздкими.

• Команды тратили больше времени на рисование, чем на разработку.

• В Agile‑среде UML казался слишком «тяжёлым».

Однако его ценность осталась: UML — это язык мышления об архитектуре. Даже если команда использует упрощённые схемы, они всё равно основаны на его идеях.

UML сегодня

Сегодня UML редко применяют в полном объёме. Но его элементы живут везде:

• Use Case диаграммы — в бизнес‑анализе.

• Sequence диаграммы — в проектировании API.

• Class диаграммы — в документации.

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

ИИ-разработка. Темп

Знаете, обычно все скрыто под NDA. Но, когда свой проект, то можно рассказать все. Сегодня я расскажу самое главное. С какой скоростью идет разработка с помощью ИИ.

Мне говорят, что 90-95% разработчиков не используют ИИ. Мне тяжело в это поверить. Я скорее поверю, что они это скрывают. Ни самим разработчикам, ни IT-компаниям невыгодно рассказывать о возросшей эффективности. Мы еще поговорим как-нибудь об этом. А пока держите эффективность моей разработки.

✔ Только что я закончил весьма тяжелый переход к новой архитектуре данных в своем проекте lanchess.ru

👀 И занял этот переход у меня 2 дня! (если считать сегодня, то 3)
Стоило это мне 10 тыс строк кода и массы тестов (и тд и тп).

А теперь внимание.
Сколько времени эта же работа заняла бы без использования ии-инструментов?
Ответ: 16-26 рабочих дня.

💥 2 дня против 1 месяца работы!

Вы пока думайте, что сказать, а я пошел дальше работать 🙂

Всегда ваш, Ланчев PRO ИИ

Матрица Эйзенхауэра в Obsidian

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

Я нашёл способ сделать матрицу Эйзенхауэра в Obsidian. 

1. Устанавливаем плагин Kanban

2. В папке .obsidian/snippets внутри вашего хранилища добавляем css-сниппет:

/* 
Author:  TfTHacker - more info  https://tfthacker.com/eisenhower-matrix-kanban
Date:    2024-02-27
LICENSE: Permission is granted to modify and distribute copies of this CSS file, that credit is given to TfThacker (https://tfthacker.com/) 
         and the source (https://tfthacker.com/eisenhower-matrix-kanban) remains linked and credited.  
*/

.kanban-plugin__board > :has(* > div > div[data-hitboxid*="e-matrix"]) {
  width: 100%;
  display: grid;
  grid-template-columns: repeat(2, 1fr);
  grid-template-rows: repeat(2, 1fr);
  gap: 15px;
  height: 100%;
  overflow-y: auto; /* constrols the vertical scrolling, which is usually disabled in the kanban board */

  .kanban-plugin__lane-wrapper {
    grid-column: span 1;
    grid-row: span 1;
    height: 100%;
  }

  .kanban-plugin__lane-wrapper:nth-child(1) > div {
    background-color: rgba(var(--color-red-rgb), 0.2);
  }

  .kanban-plugin__lane-wrapper:nth-child(2) > div {
    background-color: rgba(var(--color-blue-rgb), 0.2);
  }

  .kanban-plugin__lane-wrapper:nth-child(3) > div {
    background-color: rgba(var(--color-green-rgb), 0.2);
  }

  .kanban-plugin__lane-wrapper:nth-child(4) > div {
    background-color: rgba(var(--color-yellow-rgb), 0.2);
  }
}

body:not(.is-mobile) {
  .kanban-plugin__board > :has(* > div > div[data-hitboxid*="e-matrix"]) {
    .kanban-plugin__lane-wrapper {
      width: 100%;
    }
  }
}

body.is-mobile {
  .kanban-plugin__board > :has(* > div > div[data-hitboxid*="e-matrix"]) {
    /* make the card one line on mobile to make the matrix compact */
    .kanban-plugin__item-title {
      line-height: 1.2;
      max-height: 1.2em;
      overflow: hidden;
      text-overflow: ellipsis;
      white-space: nowrap;
    }
  }
}

3. Включаем css-сниппет в настройках в разделе "Оформление" 

4. Создаём новую канбан-доску. Её имя обязательно должно содержать фразу "e-matrix"

5. Создаём на доске 4 карточки (можно сделать пятую карточку для бэклога)

6. Получаем матрицу Эйхенхауэра с возможностью перетаскивания задач между квадрантами!!!

💬 Больше про ведение заметок и планирование в Obsidian в моём тг-канале

Представлен открытый проект Awesome OpenClaw — тщательно подобранный список замечательных ресурсов по OpenClaw — не все, но только лучшие.

Ранее был представлен открытый и бесплатный фундаментальный курс по OpenClaw, включая весь материал на русском языке с полным описанием процессов установки, настройки, использования и полноценной кастомизации ИИ‑бота под свои задачи.

Представлен открытый мультиплатформенный проект 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 — это «дедушка» ИИ (и почему тогда не взлетело):

1. Та же фигня, вид в профиль: Тогда тоже кричали: «Кодеры больше не нужны! Будем только рисовать квадратики!». Но выяснилось, что чтобы нарисовать «квадратики» правильно, нужно обладать еще более жесткой логикой, чем для написания кода. ИИ сегодня — это CASE‑система на стероидах, которая наконец‑то научилась понимать не только стрелочки, но и живую речь.

2. Проблема «Грязного входа»: В 90-х CASE‑системы разбивались о то, что люди не могли внятно нарисовать, чего они хотят. «Мусор на входе — мусор на выходе». Сейчас с ИИ ровно та же история. Если у тебя в голове каша, то никакая нейронка (как и Rational Rose в своё время) тебе рабочий продукт не выдаст.

3. Уровень абстракции: 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.