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

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

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

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

И я был очень удивлён, когда оно точь-в-точь совпало с одним из правил моего прошлого работодателя, которые он отображал на заставках ноутбуков сотрудников. По 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.

ИИ — помощник, или враг разработчика? Мысли на тему. Часть 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.

Будет интересно!